伺服器渲染

伺服器渲染(Server Side Render，以下簡稱 SSR)，真的是微前端中尷尬又難搞的存在。一般的情況，如果微前端只是單純提供純粹 HTML 字串，那本身沒什麼太困難的實作困難，輸出口處理好就好。但事實上最麻煩的其實是 hydration 這件事，如何同時處理 html 字串和 hydrate 的邏輯。

解決方案？

iframe 封裝

這是最為傳統但功能單純的作法，能夠完全不考慮 JavaScript 如何去整合，產生副作用最小，靠著原生機制去實踐。但其實這方式 SEO 並不好，本末倒置。

在伺服器端先進行載入，再進行處理與渲染

通常是先把相關的伺服器元件在需要的地方先進行載入，再即時解析和處理。但目前主流的框架，無論 Next, Nuxt 都還沒有給出很好的標準，原本應該是 build time 的東西卻變成 runtime 做只會效率很差，這麼做只會造成更大的困擾。就算把 SSR 框架做成微服務，也不能很好的共用與處理，起了很多 Client Service 卻造成巨大的資源浪費，也沒有實質解決問題，造成後續延伸問題更多。

同時提供 html 字串，並附帶 hydrate 邏輯

這幾乎是想像中最理想的解決方案，但實作 hydrate logic 這件事非常艱難不現實，又會綁定在特定實作和架構。或許對於體驗端帶來的效益可能還不錯，也同時使用上微前端分散部署的技術選型，但又何必呢？微前端要解決的事管理問題，不是客戶端問題，製造更多複雜的邏輯與技術債只會讓管理人更加困擾。

結論

現今微前端的發展技術無法在 SSR 提供很好的架構協作，付出的成本遠高於實作價值。當然我嘗試過許多 SSR 方案，但都有很多致命缺點，最後才有這樣的結論。一來是框架還不主流在解決微前端架構，二來是實作複雜度過高，會造成維護難度大幅上升。

目前微前端還是比較合適使用 CSR(Client Side Render)，應用在組合多種非同步的大型資源上，整合的相關技術相對成熟很多。或許未來技術的成熟與規範準則的統一可以更近一步改善微前端造成的問題，讓 SSR 也能享受到微前端帶來的管理效益。

但其實 SEO 需求也未必是絕對，可能你未必需要全部都是 SSR。依照需要，混合式的架構會更好，主架構採用 SSR 的主體，而需要登入或沒有 SEO 價值的功能改採用 CSR 來提供功能。

如果你知道好的 SSR 微前端解決方案，歡迎與我分享喔～～